@CodeVac513 일반 커멘트라 답글을 못 적어서 따로 커멘트 남깁니당.
코드 라인 수 이미 망했지만 그나마 지키려고 부랴부랴 올렸습니다.
그래서 PR에 코드 일관성 맞추는 건 따로 PR 다시 작성해서 작업하겠습니다. 라고 적어놨는데, 이 작업할 때 통일하려고 했어용. 이 작업 할 때,

• Controller 계층에서 어떤 건 data 변수 생성해서 반환하고, id 변수 생성하고 반환하는데, 가독성상 그렇게 도움이 되는 건 아닌 것 같아 메모리를 위해 없앨 예정입니다.
• 성윤님의 Repository 계층 재사용성에 대한 생각으로 Repository 계층 인자들을 Object가 아닌, 일반 매개 변수로 받을 수 있게 통일화 시킬 예정입니다.
• 몇몇 Controller에서 Param을 DTO를 사용하는 곳이 있고 일반 변수를 사용하는 곳이 있어 DTO로 통일할 예정입니다.
• 변수 이름 result, item 처럼 추상화 되어 있는 것들 이름 다 바꿀 예정입니다.
• DTO에 사용하지는 않지만 일관성을 위해 toResponseDtoArray를 만들어 둘 예정입니다. 나중에 사용할 수 있을 것 같고 통일성을 위해서라면 하는 게 맞다고 생각합니다.

@CodeVac513 @Jo-Minseok
저는 불필요한 toResponseDtoArray는 만들 필요가 없다는 생각인데요.

일관성이야기를 해주셨는데, 일관성이 왜 필요한가? 를 고민해 보자, 개발자가 어떤 함수나 모듈을 개발할때 "기존에 작성된 코드를 보고 한눈에 작성할 코드의 형태를 파악 할 수 있게 하기 위해서" 라는 판단을 내렸습니다.

쉽게 예를 들어보자면
아, 이번에 만든 API DTO 작성 해야되네. 다른 DTO들은 어떻게 써져 있지?
메서드 네이밍은 이렇게하고 리턴 값은 이런 형태로 쓰는구나~

위의 과정을 빠르게 가능케 하는 것이 일관성의 주 목적이라고 생각되는데요.

허나 toResponseDtoArray의 필요성을 개발자가 헷갈릴 일이 있을까요? 저는 아니라고 생각합니다. 필요성은 개발자가 개발을 진행하며 판단하는 것이고, 이렇게 혼란의 여지 없이 판단 할 수 있는 문제는 일관성과는 거리가 멀다고 생각해요.

이렇게 일관성의 이점을 챙기지 못한 상태로 단순히 '다른 메서드들도 썼으니까 얘도 써야지' 라는 생각으로 쓰는 것은 코드의 양만 늘릴 것 같다는 생각입니다.

@asn6878 그럼 필요한 곳에서만 toResponseDtoArray 함수를 생성하도록 하겠습니다! 저는 이 방법도 좋다고 생각합니다.